The present invention relates generally to the field of computer data processing, and more particularly to immunizing objects from garbage collection in object oriented programming, such as Java.
Computer programming is the method by which humans tell computers how to perform a specific task; it typically comprises lists of instructions on how to retrieve, manipulate and store data. Previously, programming was procedural or step-by-step, that is, a programmer would tell the computer to fetch data A from space A and then fetch data B from space B and then add A+B and then store the answer in space C. For the most part, computers still require those instructions but the level of sophistication has increased. One type of programming, known as object-oriented programming (OOP), is becoming increasingly popular and may eventually supplant procedural programming. OOP languages, such as Smalltalk, C++, and Java, allow programmers to approach their programming tasks in a more natural and intuitive way than the rigidity of the procedural programming languages. The goal of OOP is to reduce the time and costs associated with developing complex software by creating small, reusable sections of program code that can be quickly and easily combined and reused to create new programs. The executable code sections and the data contained therein are known as objects. The software object may model the attributes or characteristics of the real-world object and, in many cases, may also model its behavior. For example, an OOP employee object may have certain attributes of a real employee, such as a name, an address, an employee number, and so forth. Exploiting the full capabilities of the OOP source code, the employee object could be used in a program corresponding to the way one would interact with a real employee. For instance, the employee object could provide the employee""s address when asked for that information or provide the employee""s status, e.g., xe2x80x9con vacation,xe2x80x9d when asked for status information. Object-oriented databases (OODBs) that are specifically designed to facilitate storage and retrieval of objects have been developed. Objects that are stored in a data store are known as persistent objects because they xe2x80x9cpersistxe2x80x9d after the program that created them ceases executing.
Java(trademark) is a programming language that blossomed in the mid to late 1990s. The concept of Java was to remove software dependence on individual processors and into the realm of consumers, i.e., despite the fanaticism towards certain computer processors and operating systems exhibited by those knowledgeable in the computer industry, most consumers of electronic devices are irreverent when it comes to which particular processor or operating system is used to operate or function on their consumer electronic device so long as it works reliably and seamlessly. So, Java was initially developed for xe2x80x9csmartxe2x80x9d consumer electronic devices that could all be centrally controlled and programmed from a handheld remote control device, such as using the same software to operate a set-top box for video-on demand technology or a toaster. Java has flourished with burgeoning expansion of network computer technology and the rise of the world wide web browsing technology to facilitate access to the Internet. Java applications can then be written on one computer and transferred over a network, such as the world wide web, to any other consumer electronic device, such as another computer, that has a Java compiler or interpreter regardless of the operating system or the processor in that consumer electronic device.
One of the reasons Java is so productive and accepted is that Java doesn""t require the programmer to manage memory deallocations, i.e., garbage collection is automatic and is done xe2x80x9cunder the covers.xe2x80x9d In a pure Java program there""s no such thing as a memory leak that exists in C/C++ and other languages. A memory leak occurs when memory is allocated but not deallocated after the memory is unreachable by the program. Memory is allocated at instantiation of an object. The purpose of garbage collection is to automatically reclaim memory from objects that are no longer referenced. While this is a nice scheme that makes programming easier and less prone to errors, the programmer has no absolute control over when the garbage collector runs other than to manipulate some parameters, e.g., the minimum and maximum garbage collection size and the frequency with which garbage collection is done. The garbage collector typically runs periodically at the discretion of the Java Virtual Machine (JVM). Different virtual machines support different strategies for garbage collection. The bottom line is that memory is reclaimed when there are no longer any references to an object.
Garbage collection works well in most programming situations. Lack of control over memory deallocations, however, sometimes presents problems. Two problems relating to garbage collection occur in memory-constrained and real-time applications. Because the programmer has no control over exactly when memory is released, applications that are severely memory-constrained will have to rely on the garbage collector to free up memory fast enough so that no significant performance penalties have to be paid. This is typically not a problem as garbage collection algorithms are well known in the art and are usually very efficient.
In real-time applications, however, garbage collection consumes substantial system resources when its runs. In these real-time applications timing is critical and the slowdown caused by garbage collection may not be acceptable. Because there is no way to predict precisely when the memory is going to be freed, i.e., when the garbage collector is going to be activated, finding a work around is a daunting task. The Java Runtime class provided a method gc( ) to facilitate garbage collection. A call to gc( ) may be made as follows:
// Tell the garbage collector to free up memory System.gc( );
Calling gc( ), however, doesn""t deallocate memory; it is merely a suggestion to the virtual machine to run the garbage collector as soon as it can. When the garbage collector actually runs depends on the runtime environment and the implementation of the garbage collector.
Garbage collection is based on determining when an object in the runtime process is no longer in use. JVMs generate and maintain a list or table of objects contained within the JVM. As long as an active reference is in the object table, the object is reachable by the program. During the garbage collection process, the object table or list of objects is partitioned into two components: (1) active or live components; and (2) inactive objects that are no longer referenced or are dead. An object can be marked as inactive or dead so long as no other references still point to the object. Once marked as inactive, the memory can be reclaimed.
A technique for finer grain of control for Java program""s interaction with the garbage collection is Reference Object Application Programming Interface (API). The reference object encapsulates a regular reference to a Java object. The API defines the following reference types: soft reference, weak reference, and phantom reference in order of reachability. The impact on garbage collection is that the weaker the reference the more the incentive for the garbage collector to free its memory. Creating appropriate references using the Reference Object API gives the programmer more control over what memory is freed by the garbage collector but there is still no disclosed way to prevent constant objects from being reclaimed.
There remains a need, however, to improve two critical aspects of the Java environment: object creation and garbage collection. It is thus an object of the invention to reduce the amount of object creation and garbage collection that occurs in JVMs running Java applications.
These and other objects of the invention are achieved by a method of object-oriented processing which removes the creation of constant or immutable objects from method calls by elevating those objects to a static class variable. A private mutable object variable may also be elevated. These elevated objects are then stored in a root class. From the root class, a second immune object table may be created having a plurality of fixed entries, each corresponding to a respective one of the elevated objects wherein the garbage collector does not collect any of the fixed entries in the immune object table. Alternatively, elevated objects may correspond to a fixed entry in an object table and each of the respective fixed entries are marked as being immune from garbage collection.
The invention may further be realized in a method of object oriented computer processing, comprising the steps of: compiling object oriented computer code and determining if there are any fixed objects in said object oriented code. If there are fixed objects, then the method elevates them to static class variables and places them in a separate root class. A separate immune object table having a number of entries, each corresponding to one of the static class variables in the root class is created and maintained. The immune object table is then immune from garbage collection thereby retaining the values of the static class variables. Alternatively, the static class variables are maintained in an object table having all objects created by the object oriented code, but are marked as always being immune form garbage collection to retain their values.
The invention is further envisioned as an apparatus for object oriented computing, comprising means for compiling object oriented source code, means for determining if any of the objects created by the source code have constant values, and means for elevating those objects having constant values to a separate root class. The invention also has means for indicating the objects in said root class to be immune from garbage collection during execution of said source code. The indicating means may comprise means for storing the objects in the root class in an immune object table separate from an object table having variable objects; or may comprises means for fixedly marking the elevated objects in an object table to be immune from garbage collection.
It is preferred that such object-oriented code be Java. It is also preferred that such elevated objects comprise immutable objects provided by the computer programming language, private mutable object variables, and user-define immutable objects.